The following “Background” is provided to facilitate a technical understanding of the invention, and the mere inclusion of material in the “Background” shall not be construed as an admission that such material is prior art.
Bluetooth® Low Energy technology (BLE), also known as Bluetooth Smart technology, was introduced as part of the Bluetooth 4.0 specification, and is designed to enable wireless communication by devices which must rely on a small battery for an extended period of time. The Bluetooth 4.0 specification, and its successor the Bluetooth 4.1 specification, both promulgated by the Bluetooth Special Interest Group (Bluetooth SIG), having an address in the United States at 5209 Lake Washington Blvd Nebr., Suite 350, Kirkland, Wash. 98033.
One application of BLE is in the field of beacons. The term “beacon”, as used herein, refers to wireless proximity devices incorporating a BLE unit to transmit data packets of fixed length and format and including identifying information, which can be received by a compatible BLE-enabled receiving device, such as a suitable smartphone or tablet (among others) and used to determine relative proximity between the proximity device and the receiving device. A BLE unit comprises a microchip and antenna configured to transmit the data packet as a BLE-compliant low power radio signal. The transmitted radio signal containing the data packet is referred to as an “advertisement”. Software executing on the receiving device can be configured to receive and process an advertisement from a beacon to determine relative proximity to that beacon, and further configured to perform predetermined actions upon detecting specified proximity to particular beacons. By placing beacons in particular fixed locations, real-time position awareness can be provided to receiving devices, independently of other systems such as the Global Positioning Systems (GPS). For example, if a particular beacon is placed above the entrance to a bathroom in a shopping mall, a software program executing on a smartphone could be configured so that when that particular beacon is detected (i.e. because the owner of the smartphone is within BLE range of the beacon), the smartphone alerts the owner of their proximity to the beacon and hence to the bathroom. The proximity of a beacon to a receiver is determined based on relative signal strength, and in present implementations is categorized as “immediate”, “near”, “far” and “unknown”. Thus, by implementing appropriate logic in the software executing on the receiving device, or on another computer coupled to the receiving device via a suitable network, beacons can be used to enable a wide variety of location-based applications. These applications include indoor mapping and way-finding systems, as well as enabling retailers to send proximity-based notifications to customers. One skilled in the art will be familiar with the applicability of BLE and its current specification to beacon technology.
Referring now to FIG. 1, a first exemplary beacon is indicated generally at 100. The exemplary beacon 100 indicates a beacon its most basic form, which comprises a BLE unit 102 adapted to send and receive BLE radio signals, a beacon processing unit 104 coupled to the BLE unit 102 and adapted to control the BLE unit 102, a beacon storage 106 coupled to the beacon processing unit 104 and a power source 108, typically a battery, adapted to provide power to the beacon (specific connections are omitted for ease of illustration). The beacon storage 106 contains the identifying information 110 for the beacon 100. During normal operation, the beacon processing unit 104 retrieves the identifying information 110 for the beacon 100 and causes the BLE unit 102 to periodically transmit the advertisement containing the identifying information 110 for the beacon 100 (referred to as “transmitting mode”). The identifying information 110 for the beacon 100 can be replaced with new identifying information; a suitable BLE-enabled device can transmit a signal to the BLE unit 102 which causes the beacon processing unit 104 to initiate logic for receiving new identifying information for the beacon 100 and for writing the new identifying information for the beacon 100 to the beacon storage 106 (referred to as “receiving mode”). While shown as separate blocks in FIG. 1 for purposes of illustration, one skilled in the art will appreciate that one or more of the BLE unit 102, beacon processing unit 104 and storage 106 may be integrated into a single unit.
Beacons may include additional components as well. FIG. 1A shows a second exemplary beacon 100A, which is similar to FIG. 1 and in which like references denote like features, but with the suffix “A”. The beacon 100A, in addition to the BLE unit 102A, beacon processing unit 104A, beacon storage 106A and power source 108A, also includes a temperature sensor 112A and a motion sensor 114A (e.g. an accelerometer), both coupled to the beacon processing unit 104A. Thus, some beacons may transmit data packets that include additional information beyond the identifying information for the beacon. The temperature sensor 112A and motion sensor 114A are merely examples of additional sensors that may be included as part of a beacon; beacons may be provided with a wide array of additional sensors and components.
There are currently four major published beacon protocols for transmitting the advertisement (the data packet containing the identifying information for the beacon): iBeacon, sBeacon (also referred to as s-beacon), AltBeacon and Eddystone. The iBeacon protocol is promulgated by Apple Inc., having an address at 1 Infinite Loop, Cupertino, Calif., U.S.A. 95014. Information about the iBeacon protocol is available at https://developer.apple.com/ibeacon/. The AltBeacon protocol is promulgated by Radius Networks, Inc., having an address at The Powerhouse, 3255 Grace Street NW, Washington, D.C., U.S.A. 20007. Information about the AltBeacon protocol is available at http://altbeacon.org/. The Eddystone protocol is promulgated by Google Inc., having an address at 1600 Amphitheatre Parkway, Mountain View, Calif. 94043, U.S.A. Information about the Eddystone protocol is available at https://developers.google.com/beacons/?h1=en. The sBeacon protocol was promulgated by Signal360, Inc. (formerly Sonic Notify Inc.), having an address at 251 5th Ave, Fla. 6, New York City, N.Y., U.S.A. 10016.
Under the present BLE standard the advertisement comprises a 37-octet hexadecimal string which contains identifying information for the beacon. For iBeacon, s-beacon and AltBeacon, the identifying information for the beacon includes a leading sixteen octet universally unique identifier (UUID) for the beacon, followed by a two octet first profile identifier for the beacon, followed by a two octet second profile identifier for the beacon. For example, in the iBeacon format promulgated by Apple Inc., the advertisement comprises an octet indicating the overall length of the advertisement, followed by a second octet set to 0xFF, followed by an octet set to 4C00 (the company ID for Apple Inc.), followed by an octet for data type, followed by an octet for length, followed by the sixteen-octet UUID, followed by the two-octet first profile identifier called “major”, followed by the two-octet second profile identifier called “minor”, followed by an octet indicating calibration power. In the iBeacon protocol and the sBeacon protocol, the UUID is referred to simply as “UUID”, in the AltBeacon protocol the UUID is referred to as “ID1”; in each case it is a sixteen-octet string and provides the same functionality. In the Eddystone protocol, the identifying information for the beacon is an eight octet string which includes a leading five-octet UUID referred to as “Namespace” followed by a three octet profile identifier for the beacon, referred to as “Instance”. For simplicity, the term “UUID” is used herein to refer to the leading identifier (e.g. the leading sixteen-octet identifier in the iBeacon, sBeacon and AltBeacon protocols and the leading five-octet “Namespace” identifier in the Eddystone protocol), regardless of the beacon protocol.
Typically, each manufacturer ships its beacons with the identical default UUID, although the first profile identifiers and second profile identifiers may differ (e.g. they may be assigned randomly). The user or installer of the beacons sets the UUID, first profile identifier and second profile identifier to appropriate values so that they will be recognized by the logic of the software program executing on the receiving device. For example, a chain of retail stores may set all of the beacons in all of its locations to have identical UUIDs so that a dedicated mobile phone software application for that chain of retail stores would search for beacons having that UUID.
The first profile identifier can be used to notionally collect beacons into a group, and the second profile identifier can identify individual beacons within a group. Continuing the example of a chain of retail stores, all of the beacons in a particular store location may be given the same first profile identifier to identify that store location, and then individual beacons may be given different second profile identifiers to denote different locations within the store. In the iBeacon protocol, the first profile identifier and the second profile identifier are referred to as “major” and “minor”, respectively and in the AltBeacon protocol the first profile identifier and the second profile identifier are referred to as “ID2” and “ID3”, respectively. In the sBeacon protocol the first profile identifier and the second profile identifier are collected into a single string referred to as “SID” which can be notionally separated into a first profile identifier component and a second profile identifier component. Similarly, in the Eddystone protocol the three octet “Instance” profile identifier can be notionally separated into a first profile identifier component and a second profile identifier component.
In a multi-beacon environment, the UUID, first profile identifier and second profile identifier must be set individually for each beacon in order to distinguish the beacons from one another. This is a time-consuming process, since it requires sufficient proximity to the beacon whose values are being changed. Moreover, having manufacturers ship beacons with the UUID, first profile identifier and second profile identifier pre-set to the desired values is not a viable solution, since it still requires the user or installer to individually determine the UUID, first profile identifier and second profile identifier for each beacon (i.e. which pre-set beacon is which) to ensure that each beacon is positioned where it should be positioned.
Accordingly, the labor-intensive process required to set or determine the UUID, first profile identifier and second profile identifier for each beacon deployed presents a significant obstacle to the adoption of beacon technology.